United Public Domain Gold 2/United Public Domain Gold 2.iso/education/pe022.dms/pe022.adf/GRAVSIM/README

Text File | 1991-07-12 | 6KB | 182 lines

    THE GRAVITY SIMULATOR:         Page 1




                  A  Gravity Simulator Animation Program

                                    by

                         Richard Frost. (C) 1988



      Compilation:

           My program compiles under  both  Aztec  3.6a  and 3.2a. The
    program runs easily with  1/2  Meg  and  will load the sprite data
    into chip ram and the rest of  the  program  into FAST RAM (If you
    are lucky enough to have any!!!).

           This program is a real number cruncher and would BURN with
    one of those 68020 and 68881 TURBO BOARDS!!


       Bugs:

           Not many, I am happy to say !.  But there is this weird bug
    that occurs if  you are  in  the  RECORD  mode  and  you add a new
    planet. Then, when you  try  to  play  the  animation  back... you
    guessed it !, you get a visit from the friendly neighbourhood GURU
    !



      Basic Program Description:

           My program can animate up to  6  planetary  masses  all  of
    which exert  a  mutual  gravitational  force  on  each  other. The
    planetary masses can be placed  and  removed  from anywhere on the
    screen and their mass and  initial  velocity can all be determined
    by the user. The program then steps the animation through time, at
    each stage plotting the new  position  in  the trajectory for each
    mass on the screen. The animation  in this mode is obviously going
    to be slow as the computer is calculating  the paths in real time.
    It is for this reason  that  I  have  used  a  large array storage
    technique involving the  use  of  a  look-up  table  to record the
    positions of the masses for  each  step  in time. A record mode is
    offered which allows the user at any  time to record the animation
    calculated in real time  and  then  play  it  back at a variety of
    speeds, this mode is useful as  the  complex  interactions between
    various masses can be more  easily  appreciated when the animation
    is played back at full speed.





    THE GRAVITY SIMULATOR:         Page 2



      Theory behind the animation:

           To animate N bodies, each applying some gravitational force
    on all the other bodies we must consider  1 mass at a time and for
    that mass evaluate the total force  vector applied to the mass due
    to the gravitational force of  attraction  from  all the remaining
    masses. We then work out the the new acceleration of the mass from
    Newton's First Law and hence  it's  new  velocity and position. In
    real life however, it  things  are  not  as  simple as this. In my
    model  animation  I  have  ignored  possible  quantum  gravitional
    effects such as  the  curvature  of  space-time  and  non constant
    acceleration. My model behaves quite  well under the assumption of
    constant acceleration,  this  allows  me  to use the simple motion
    equation: V2 = V1 + At, which  increases  speed of calculation, as
    equations  involving  non  constant   acceleration  would  involve
    possible  Differential  Equations  and  numerical  methods,  for 3
    situations involving 3 or more  masses.  My assumption of constant
    acceleration is not incorrect  as  long  as I choose steps in time
    which are relatively small when  compared  to  the mutual force of
    attraction between 2 given masses .

            Some problems do  arise  when  2  masses  get  very  close
    together. In this situation the gravitational  force is very large
    (inversely proportional to the square  of the separtation of the 2
    masses) and consequently if I  keep  the same icrements in time as
    when the masses are far apart,  for  the next frame the masses may
    pass each other by  and  thus  have  the  same  velocity vector as
    before the  encounter  took  place.  This  results  in both masses
    heading off to  infinity  (leaving  the  screen  very quickly) and
    ending the animation. I partially  solved this problem by refining
    (reducing) my  time  increments  appropriately  (in  fact  I use a
    linear reduction which depends on the separation of the 2 masses.)
    this  is  seen  in   the   section   of   C-code  in  the  routine
    GravityAttract which obtains the  new  X & Y velocities of a given
    mass   M1 due to the force applied by mass M2 :

                  If (r < 2000 )
                    {
                      TimeStep = r * 0.04 + 1;
                    }
                  else
                      TimeStep = 80.0;

    where 'r' is the separation of the 2 masses. The number '0.04' was
    arrived at after af few  runs  of  the  program  and analysing how
    close planets could get without unexpectantly  leaving the screen.
    This code part worked quite well  and  reduced the number of times
    planets would fling off  and  leave  the  screen when they got too
    close. This   problem  is  always  there  and  is  inherent in its
    algorithmic description, I know of  no other simple technique that
    comlpletely solves this problem.


      Extra Notes:




    THE GRAVITY SIMULATOR:         Page 3



         Because of my program's  generality  it is possible to set up
    animations involving the  animation  of  say, comet paths around a
    star or very massive object and the familiar wobble motion a start
    exhibits when it has  planets  orbiting  it  (Astronomers look for
    this motion of a star to determine whether it has planets orbiting
    around it. Also, due to the  way  I  store  the position values of
    masses  in the look-up  table,  masses  are  animated with various
    speeds, this is due to the storing  of multiple copies of the same
    position of a given mass in the  look-up  table.  I decided not to
    store a position value and a count  as my table uses more then one
    object thus you cannot  have  situations  where  large consecutive
    portions of the array contain the same postion values.